Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1101

Internet Message Format | 1994-08-27 | 13KB

Date: Thu, 28 Jul 1994 12:20:36 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Gem List
To: [e-mail]
In-Reply-To: <71940728015817/[e-mail]>
Message-Id: <Pine.3.87.9407281235.A14224-0100000@grad>
Mime-Version: 1.0
Precedence: bulk



On Wed, 27 Jul 1994, Daniel J. Hollis wrote:

> Subject:  GEM, etc.
>
> Whomever (again; I think this is the same one I answered too...):
> -----------------------------------------------------------------
> > Well, after much thought, I have decided to abandon the German
> > user-interface attitude of so overloading the interface with [sometimes
> > marginally useful] features that the program becomes unusable.
>
> Care to tell us *exactly* which 'marginally useful' features you mean?

Any features which make the display confusing, overload the user with too
many options to choose from, or simply wouldn't get used, yet it's included.

>
> > I see absolutely no point in going through all the trouble of adding
> > countless features and options, 90% of which will not be used in any
> > particular situation.  I want a window-library that makes my life easy
> > with documentation that takes me less than a week to read and understand,
> > well-commented, readable code, and simple bindings.
>
> Care to elaborate on *exactly* which "90%" will not be used? I hope you're
> not talking about stuff like dialogs in windows, background button
> activation, and listboxes. Those are *essential* to a good windowing library.
> Abandon those and you abandon any point in writing a library at all.

The Germans seems to have this tendancy toward making the user interface
as complicated as possible.  They will give the user too many options.
Perhaps 90% was an exageration... perhaps not.

>
> In terms of complexity, you can write a fully working GEM program that
> lets you put dialogs in windows, move them around, close them, iconify
> them, click buttons in background, etc. with only about 10 lines of code
> (using XAES).

You can with my library too.  I'm sure you can with any of our
libraries.  It makes sense to have all that built in.

>
> Simple bindings: #include <xaes.h>
>
> Difficult, eh?

Bindings:  the function calls you use and what parameters are passed.

>
> XAES's documentation includes lots of examples, something that lots of other
> libraries documentation fail to include. Maybe it's time they should start.
>

I am a technical writer and technical editor.  I am a fanatic about
making certain that documentation is good.  Mine will be good.

> > I see no point in absolutely abandoning the GEM style.  It makes sense to
> > make some modifications, yet some of the things you people are talking
> > about like sending key-presses to a background window are not only hard
> > to implement and counter-intuitive, but possibly DANGEROUS.  I will not
> > send keypresses to a background window, and unless it's absolutely
>
> Nobody should *ever* send keypresses to anything but the window under
> current focus. It is *incredibly* confusing to do otherwise. Just flip
> this option on in some X11 window manager and you'll learn really damn
> quick to hate it (as well as auto-window topping.. this is a totally
> STUPID idea!)

Some times it's OK once you get used to it, but not for GEM.

>
> By the way, I'm not sure what you mean by 'abandoning the GEM style'. There
> really is none! There is almost no consistency in GEM user interfaces,
> the way things work under different versions of TOS, etc.

I'm talking about abandoning the way GEM functions.  For example, the
closer should not pop up a menu (except in circumstances where it's
really useful, but let's not make a habbit of it).  This change in style
will do nothing but confuse and frustrate the user because he has to
contend with another dialog.

And too much stuff involving the background windows will also just be
confusing.

>
> I thought what we were trying to do here is establish *standards*, but if
> you're content on living with *no* standards, go right ahead.

I didn't say I wanted NO standards.  I want UNCONFUSING and SAFE
standards.  I'd think you'd have realized that by now.

>
> > necessary, I don't see any point in sending mouse-clicks to a background
> > window either.  It's just not GEM and it will only confuse and frustrate
> > people.
>
> Cop out. It's simple to do, a great convenience to the user as well. It
> will frustrate people more if they have to top every damn window just to
> use its gadgets, or if they have to induce hand cramps to drag a background
> window. If a user has more than 5 or 6 windows up, your interface will only
> get in the way and hamper the user, something a library should NEVER do.
>

I KNOW it's simple to do.  Even under normal TOS, my library already has
the option to do that... for the dialogs anyway.  I use it for tool boxes.

> > I see no point in screwing with GEM's top-window-had-focus method.  A
> > tool bar in a background window doesn't, as far as I'm concerned, have
> > focus when you click on it, so it's just fine with me.  I do not like
> > giving focus to anything other than the top window.  The X-windows method
> > is OK, but we're not using Xwindows... we're using GEM.  Don't forget that.
>
> Fine, be content living in 1985. The rest of the world will leave you behind,
> along with MS-DOS 3.3.

If living in 1985 lets me get more work done faster and easier, then so
be it.  I'm not one to hold back progress, but if this 'progress' is
radical to the point that it only makes things more confusing and harder
to work with, then I don't want it!

>
> > I want users to like my applications.  I want users to be able to use my
> > applications.  Therefore, I will give the user only what he needs to be
> > able to accomplish his task effectively.
>
> Sounds like you really mean 'programmer' here rather than 'user'.
> And if your interface is so primitive that no user will ever want to use
> it, what's the point? Nobody will want to use a library that is going to
> be too restrictive on the programmer and user.

Both, but the user is more important than the programmer in many cases.
If the user is happy, then the programmer makes money, even if it took
him an extra few hours.  I realise this could be used in support of the
app-defs file, but I have other reasons I don't like it.

>
> > With that, I have to ask what is in some of these other libraries that
> > take up over 200k?  Loads and loads of more features.... most of which
> > someone looking to get work done would never use.
>
> And that only get linked in if you use them. Some people don't seem to
> understand that even if a library is 400k, applications aren't necessarily
> going to be large. Only if you use things will they get linked in. It just
> means that with that particular library, you have more options to choose
> from -- a larger 'toolbox' so to speak.

Well, I break my library down into a few seperate .C files and the
programmer can pick which ones he wants.  I'm sure that's what most of us do.

>
> The test application for XAES that excercises the basic library functionality
> (dialogs in windows, iconifiable windows, background buttons, etc. etc.)
> only takes about 50k. That's for the full compiled application. That's not
> so big is it?

I don't know if it's big.  I don't know what it does.  Let me put it this
way... if mine does the same amount or more and it's smaller, than yours
it too big.  We'll see.

>
> > My library will continue to grow, but I doubt it will grow to more than
> > 50k, and I will always strive to make it simpler and simpler to use while
> > it gets more and more powerful.
>
> Kind of a contradiction here ;-) By limiting the size to 50k, you more or
> less limit what you can do with the library. At some point you will hit
> a brick wall.

I'm not LIMITING it to 50k.  Why don't you read it again?  I said, "...I
doubt it will grow to more than 50k...."  This means it probably won't,
but if it does, no biggie.  I'll have a good reason for it.  :)

>
> > ]No, you just convert the WF_TOPPED message to button